Load switch command including identification of source server cluster and target server custer

ABSTRACT

A software defined network (SDN) controller sends a load switch command to a network device. The load switch command includes identification of a source server cluster and identification of a target server cluster.

CLAIM FOR PRIORITY

The present application is a national stage filing under 35 U.S.C. § 371of PCT application number PCT/CN2014/079422, having an internationalfiling date of Jun. 6, 2014, which claims priority to Chinese patentapplication number 201310231992.4, having a filing date of Jun. 9, 2013,the disclosures of which are hereby incorporated by reference in theirentireties.

BACKGROUND

Enterprise data centers may provide services to users through a servercluster approach. A server cluster may include a plurality of physicalservers or virtual servers to provide the same service, for example,such as web access service. A load balance device (LBD) is deployed atthe front end of a cluster. According to a predetermined load balancingalgorithm, the LBD may distribute access requests initiated fromexternal hosts to different servers in a server cluster for furtherprocessing, and then the LBD sends responses returned from the serversto the external host.

BRIEF DESCRIPTION OF DRAWINGS

Features of the present disclosure are illustrated by way of example andnot limited in the following figure(s), in which like numerals indicatelike elements, in which:

FIG. 1 is an example of a schematic of illustrating a software definednetwork (SDN);

FIG. 2 is an example of a block diagram illustrating a SDN controller;

FIG. 3 is an example of a flowchart of load balancing across cluster;

FIG. 4 is an example of a block diagram illustrating part of a networkdevice;

FIG. 5 is an example of a flowchart of load balancing across cluster ina network device of FIG. 4; and

FIG. 6 is an example of flowchart of load balancing across clusters in aSDN controller.

DETAILED DESCRIPTION

For simplicity and illustrative purposes, the present disclosure isdescribed by referring mainly to an example thereof. In the followingdescription, numerous specific details are set forth in order to providea thorough understanding of the present disclosure. It will be readilyapparent however, that the present disclosure may be practiced withoutlimitation to these specific details. In other instances, some methodsand structures have not been described in detail so as not tounnecessarily obscure the present disclosure. As used herein, the terms“a” and “an” are intended to denote at least one of a particularelement, the term “includes” means includes but not limited to, the term“including” means including but not limited to, and the term “based on”means based at least in part on.

In an example, load balancing across clusters is implemented under thecontrol of a software defined network (SDN) controller. FIG. 1 is aschematic of illustrating part of a software defined networks (SDN) inone or more examples of the present disclosure. Referring to FIG. 1, inthis example, the software defined network includes a SDN controller 11,a first server cluster 12, a second server cluster 13, an external host14, a network device 151 and a switch 161. The first server cluster 12includes a plurality of servers S11, S12 . . . S1 n and a first loadbalance device (LBD) 121, and the second server cluster 13 includes aplurality of servers S21, S22 . . . S2 n and a second LBD 131. Theexternal host 14 sends access requests to the servers S11, S12 . . . S1n, S21, S22 . . . and S2 n. The LBD 121 is responsible for calculatingand balancing the loads of these servers in the first server cluster 12,and the LBD 131 is responsible for calculating and balancing the loadsof these servers in the second server cluster 13. The packets of theaccess requests of the external host 14 will be sent to thecorresponding servers for servicing through the network device 151, theswitch 161 and the LBD 121, 131.

FIG. 2 is a block diagram illustrating a SDN controller 11 in an exampleof the present disclosure. As shown in FIG. 2, the SDN controller 11includes a processor 111, a memory 112, a non-volatile storage 113 and anetwork interface 114. The memory 112, the non-volatile storage 113 andthe network interface 114 are accessible by the processor through theinternal bus 115. The non-volatile storage 113 stores modules of machinereadable instructions executable by the processor 111 including a loadswitch command module 117. As explained in more detail later, the loadswitch command may cause a second server cluster to respond to an accessrequest addressed to a first server cluster. i.e. it may transfer thelogic of access across clusters. The non-volatile storage 113 in whichthe machine readable instructions are stored may be a non-volatilememory or storage media including by way of example semiconductor memorydevices, e.g., EPROM, EEPROM, DRAM and flash memory devices; magneticdisks, e.g., internal hard disks or removable disks; magneto opticaldisks; and CD ROM and DVD-ROM disks. The memory 112 may be a volatile ornon volatile memory, including by way of example semiconductor memorydevices, e.g., EPROM, EEPROM, DRAM and flash memory devices etc. Asshown in FIG. 2, the processor 111 of the SDN controller 11 reads aprogram which includes the switch command module 117 stored in thenon-volatile storage 113 to memory 112 and executes the switch command.Both the memory 112 and the non-volatile storage 113 are examples ofnon-transitory computer readable storage media. The memory 112 may alsostore a cross-cluster table 116 which is described in more detail below.

FIG. 3 is a flowchart of a method for the SDN controller 11 which hascompleted load balancing across server clusters in an example of thepresent disclosure. As shown in FIG. 3, in block 301, the SDN controller11 obtains load information which is reported by a source servercluster. In block 302, the SDN controller updates the state of thesource server cluster in a cross-cluster table 116 in accordance withthe load information. The cross-cluster table 116 may be stored in thememory 112. The storage of the cross-cluster table in the memory 112 maybe temporary.

At block 303 the SDN controller 11 determines that the source servercluster is in an overload state.

At block 304, in response to determining that the source server clusteris in an overload state the SDN controller 11 searches the cross-clustertable to find a search target server cluster that is in an idle stateand which is located in the same server cluster group as the sourceserver cluster.

At block 305, the SDN controller 11 sends a load switch command to apredetermined network device which is located in a front path of thesource server cluster, wherein the load switch command hasidentification of the source server cluster and identification of atarget server cluster. The load switch command may be sentsimultaneously with the searching of the cross-cluster table.

In an example, the target server clusters which belong to the sameserver cluster group as the source server cluster are as follows: theserver clusters that are in idle state and can provide same service ofthe source server cluster to the external host. For example, as shown inFIG. 1, the first server cluster 12 and the second server cluster 13belong to the same server cluster group X1. The front path is definedas: a path between a LBD of the source server cluster and an externalhost. The LBD may be considered as a starting point of the front pathand an external host may be considered as an end point of the frontpath. The external host may initiate a session request with the sourceserver cluster. For example, in FIG. 1, the front path is starting fromthe first LBD 121 to the external host 14. Any network device withcorresponding processing capability in the front path can be designatedas the predetermined network device. The predetermined network device,for example, can be the first LBD 121, or other network device such asthe network device 151 or switch 161.

In the following example, the predetermined network device is a router,but in other examples it may for instance be a high-performance switch,or security equipment that is responsible for security etc, and is notlimited to being a router. In the example of FIG. 1 the predeterminednetwork device 151 is a router and as such the SDN controller 11 isshown as having a connection to the router 151. In other examples whereanother network device, such as LBD 121 or switch 161, is thepredetermined network device, said another network device may have adirect or indirect connection path to the SDN controller.

In a SDN, the flow table entries are distributed by a SDN controller toa SDN switch or other network device, and the SDN switch can determinehow to forward packets based on those flow table entries. In an exampleof the present disclosure, the interaction between the SDN controllerand the LBD of a server cluster may be able to perform further functionsrelating to the load of a server cluster or which server cluster shouldbe used. In an example, a LBD belongs to the server cluster and can sendload information of the server cluster to a SDN controller. The SDNcontroller determines the state of the corresponding server clusteraccording to the load information which is uploaded by the LBD, andupdates the corresponding records in the cross-cluster table. Table 1 isschematically shown the cross-cluster table in one or more examples ofthe present disclosure. In Table 1 the abbreviation SC stands for servercluster.

TABLE 1 SC Group ID SC ID SC State X1 SC12 idle SC13 idle SC14 idle X2SC15 idle SC16 idle

The load information may for example be quantitative load sizeinformation, such as the number of sessions for characterizing the loadsize information. In another example, the load size information may becharacterized by the share rate of the processor of a LBD or a server.In the following examples, the number of sessions will be described forillustrative purpose, but it is to be understood that other metrics maybe used to indicate the load. In other examples the load information maybe qualitative load state information such as state informationindicating idle load or overload, rather than quantitative load sizeinformation.

In an example, assuming the first server cluster 12 is the source servercluster, the SDN controller 11 obtains the load information of the firstserver cluster 12 wherein the load information is uploaded by the firstLBD 121, then the SDN controller 11 can determine whether the firstserver cluster 12 is in an overload state. The determination of thefirst server cluster 12 in the overload state by the SDN controller 11is associated with the load information uploaded by the first LBD 121.When a new session is created, the session information is uploaded tothe SDN controller 11 by the first LBD 121. When a session is deleted,the first LBD 121 also notifies the SDN controller to perform deleteoperation in synchronicity. Thus, the SDN controller 11 can timely keepa copy of the session list of the first server cluster 12 in which thefirst LBD 121 preserved, and can determine the number of currentsessions of the first server cluster 12. On this basis, the SDNcontroller 11 may compare the number of current sessions of the firstserver cluster 12 with various predetermined thresholds to determinewhether the first server cluster 12 is in the overload state.

For example, assuming that a switch threshold of the first LBD 121 is10,000 sessions and a total switch threshold which is a summation ofsession processing capability of all the servers in the first servercluster is 15,000 sessions, then the whole bottleneck of the firstserver cluster 12 is limited to the processing capability of the firstLBD 121. When the SDN controller 11 finds that the number of currentsessions of the first server cluster 12 reaches 10,000 sessions, the SDNcontroller 11 can decide that the first server cluster 12 is in theoverload state because the number of sessions of the first LBD 121reaches to the switch threshold. In an another example, assuming thatthe processing capability bottleneck of the first LBD 121 is 10,000sessions, the bandwidth bottleneck of the first LBD 121 is 8,000 Mbps,and each session occupies 1 Mbps, in fact, the SDN controller 11 candecide that the first LBD 121 is in bandwidth bottleneck when the numberof sessions reaches 8,000. At this time, the SDN controller 11 candecide that the first server cluster 12 is in the overload state. In afurther example, assuming that the first LBD has high performanceprocessing capability, and the processing capability of each server inthe first server cluster 12 is weak, for example, the summation ofsession processing capability of all of the servers in the first servercluster 12 is 7,000 sessions, then the servers in the first servercluster 12 will reach processing bottleneck first. Meanwhile, the SDNcontroller 11 can decide that the first server cluster 12 is in theoverload state.

In the aforementioned examples, the first LBD 121 is responsible toupload the quantitative load information of the first server cluster 12to the SDN controller 11. The SDN controller 11 determines whether thefirst server cluster 12 is in the overload state by calculation. In ananother example, when the processing capacity of the first LBD 121 isstrong, the first LBD 121 can calculate the load state information byitself, and then upload to the SDN controller 11. The first LBD 121undertakes the calculation task of the SDN controller 11. In this case,the creation of a new session or the deletion of a session by the firstLBD 121 is need not be uploaded to the SDN controller 11. Rather, whenthe first LBD 121 finds that the first server cluster 12 enters theoverload state or exits from the overload state, the LBD 121 reportsthis change to the SDN controller 11. At this time, the first LBD 121reports the qualitative load information characterizing the load statechange of the first server cluster 12. The SDN controller 11 is nolonger necessary to calculate for determining the state of the servercluster.

Please refer to FIG. 3, when the SDN controller 11 determines that thefirst server cluster 12 enters to the overload state, the SDN controller11 updates the record of the first server cluster 12 in the table 1. Thestate of the first server cluster 12 is changed from the idle state tothe overload state, and the table 1 is updated as shown in the table 2.The SDN controller 11 searches the table 2 to find a search targetserver cluster that is an idle state which is located in the same servercluster group as the first server cluster 12. In this case, assuming itcan find that the second server cluster 13 is in the idle state fromlooking the table 2 up. The SDN controller 11 designates the secondserver cluster 13 as a target server cluster to share the new access tothe first server cluster 12.

TABLE 2 SC Group ID SC ID SC state X1 SC12 overload SC13 idle SC14 idleX2 SC15 idle SC16 idle

In the initialization process, the network administrator can assign thefirst server cluster 12 and the second server cluster 13 into the sameserver cluster group X1 because both provide the same services toexternal hosts, such as access to specific web services. Similarly, thenetwork administrator can assign a server cluster 14, a server cluster15 and a server cluster 16 into another server cluster group X2 becausethose offer the same service to external hosts, such as specificstreaming media dispatch services (server clusters 14, 15 and 16 areshown in Table 2, but are not shown in FIG. 1).

After finding the second server cluster 13 which is in the idle state,the SDN controller sends load switch command to a predetermined networkdevice which is located in a front path of the first server cluster 12.The predetermined network device can be any network device withcorresponding processing capability located in the front path, whereinthe front path is a segment path that is starting from the first LBD 121to the external host 14. Thus, according to the different predeterminedpolicy of the network administration, the predetermined network devicecan be the first LBD 121, or other network device such as the networkdevice 151 or switch 161 etc. In an example, the SDN controller 11 sendsload switch command to the network device 151 for requesting the networkdevice 151 to transfer the new access of the first server cluster 12 tothe second server cluster 13. Thus, it can avoid the load degenerationof the first server cluster 12. After receiving the load switch commandwhich carries the identification of the first server cluster 12 and thesecond server cluster 13, the network device 151 can make sure that itneeds to transfer the new access of the first server cluster 12 to thesecond server cluster 13. The network device 151 now performs a switchprocessing mode for the source server cluster. FIG. 4 is a block diagramillustrating a predetermined network device, such as a router in anexample of the present disclosure.

Please refer to FIG. 4; the network device 151, which may for example bea router, switch or LBD etc, includes a processor 1511, a memory 1512, anon-volatile storage 1513 and a network interface 1514. The memory 1512,the non-volatile storage 1513 and the network interface 1514 areaccessible by the processor through the internal bus 1515. Thenon-volatile storage 1513 stores modules of machine readableinstructions executable by the processor 1511 including a load switchcommand module 1517. As explained in more detail later, the load switchcommand may cause a second server cluster to respond to an accessrequest addressed to a first server cluster. I.e. it may transfer thelogic of access across clusters. The non-volatile storage 1513 memory inwhich the machine readable instructions are stored may be a non-volatilememory or storage media including by way of example semiconductor memorydevices, e.g., EPROM, EEPROM, DRAM and flash memory devices; magneticdisks, e.g., internal hard disks or removable disks; magneto opticaldisks; and CD ROM and DVD-ROM disks. The memory 112 may be a volatile ornon volatile memory, including by way of example semiconductor memorydevices, e.g., EPROM, EEPROM, DRAM and flash memory devices etc. Asshown in FIG. 4, the processor 1511 of the network device 151 reads aprogram which includes the switch command module 1517 stored in thenon-volatile storage 1513 to memory 1512 and executes the switch commandmodule 1517. Both the memory 1512 and the non-volatile storage 1513 areexamples of non-transitory computer readable storage media. The memory1512 may also store a cross-cluster table 1516 which is described inmore detail below.

FIG. 5 is a flowchart of a method for load balancing across serverclusters in a network device of FIG. 4 in an example of the presentdisclosure. As shown in FIG. 5, in block 501, the network device 151receives the load switch command from a software defined networks (SDN)controller 11 wherein the load switch command has identification of asource server cluster and identification of a target server cluster, andperforms a switch processing mode for the source server cluster. Thenetwork device 151 has at least two operation modes for a same servercluster. One operation mode is a switch processing mode and the other isa load switch-back mode. In different operation mode, the process of thenetwork device 151 will be different. When the network device 151receives the load switch command, the network device 151 performs theswitch processing mode which includes the following operations.

In block 502, the network device 151 receives packet for accessing thesource server cluster in the switch processing mode.

In block 503, the network device 151 determines whether the packetbelongs to a session which has been established for the first servercluster 12, and if it determines the packet belongs to session which hasbeen established for the first server cluster 12 (503—yes), then thenetwork device 151 processes to block 505, otherwise, it processes toblock 504.

In block 504, the network device 151 acts as proxy for an external hostto access the second server cluster 13. That is, the network device 151modifies the source IP address of a request packet from the externalhost and then forwards the modified request packet to a target servercluster.

In block 505, the network device 151 forwards the packet to the firstserver cluster 12.

More detailed examples are provided in the following for illustration.When the first server cluster 12 enters to the overload state, in orderto maintain the consistency of the service, if the access packet fromthe external host 14 belongs to a session which has been established forthe first server cluster, the packet still needs be sent to the firstserver cluster for processing. According to the session listed tablewhich has been established for the first server cluster, the networkdevice 151 can determine whether a packet is belonged to a session whichis generated for a new access after the first server cluster 12 enteringto the overload state. In this example, excepting for sending controlcommand to the network device 151, the SDN controller 11 also transmitsthe session list table of the first server cluster 12 to the networkdevice 151 in synchronicity, wherein the session list table is send fromthe first LBD 121. Please refer to the Table 3 for an example. Inanother example, if the SDN controller 11 already has a copy of thesession list table in itself, the first LBD 121 does not need to sendrepeatedly.

TABLE 3 SC ID No. SIP DIP SPort DPort Protocol Type SC12 1 1.1.1.22.2.2.2 123 8080 TCP 2 1.1.1.3 2.2.2.2 123 8080 TCP 3 1.1.1.4 2.2.2.2123 8080 TCP . . . . . . . . . . . . . . . . . . n 1.1.121.2  2.2.2.2123 8080 TCP

After the first server cluster 12 entering to the overload state, whenan access request of the first server cluster 12 arrives at the router151, the network device 151 can search the session list table of thefirst server cluster 12 based on the session characteristics of therequest to query whether there is a matched record. If the query ishitting, it indicates that the packet belongs to an established sessionof the first server cluster 12. Then, the network device 151 cantransparently forward the packet to the first LBD 121 in order toimplement the access of the first server cluster 12. If the query ismissing, it indicates that the packet belongs to a new session which isestablished after the first server cluster 12 entering to the overloadstate. The packet of the new session which is established after thefirst server cluster 12 entering to the overload state needs to betransferred to the second server cluster 13 for processing.

Please continue to refer to FIG. 1; the network device 151 willobviously forward the access packet of the second server cluster orother server cluster. Thus, the network device needs to filter out thepacket which accesses the first server cluster from the all packets andthe filtering method can be flexible. In an example, the network device151 may first issue the access control list (ACL) classification rulesof the packet to a corresponding external port such as Port 1 shown inFIG. 1. Thus, all the packets that access the first LBD 121 can befilter out. Of course, the interactions between the SDN controller 11and the first LBD 121 are not necessary to filter out, so the ACLclassification rules require reasonable defined. After packet filterbeing completed, the network device 151 can be used as proxy to achievethe transfer of access. In the present example, the network device 151may modify the IP address and other necessary parameters of the originalpacket to act as proxy for the external host 14 to access the second LBD131, and the network device 151 keeps the modification relationships inlocal.

After receiving the modified packets, the second LBD 131 based onpredetermined processing rules will dispatch the access packets to theservers in the second server cluster 13 for processing. The server inthe second server cluster 13 sends back a response packet to the secondLBD 131 after finishing processing the access request. When the networkdevice 151 receives the response packets from the second LBD 131, thenetwork device 151 modifies the response packets in accordance with thepreserved modification relationships, and then sends to the externalhost 14. Thus, the network device 151 completes the role of proxy forthe external host 14, and the modification of the packets is transparentto the external host 14 and the second LBD 131.

When the first server cluster 12 enters to the overload state, the firstLBD 121 can still periodically upload the load information. All the newaccess for the first server cluster 12 is been transferred to the secondserver cluster 13. At this time, the number of sessions of the firstserver cluster 12 will be decreasing rather than increasing. Forexample, when some external host does not need the service of the firstserver cluster 12, the external host will exit the session. The numberof the original session of the first server cluster 12 will decreasewhich leads the first server cluster 12 to exit the overload state. Inan example, the SDN controller 11 sends load switch-back command to thepredetermined network device to cancel the transfer of new access when aswitch-back threshold is met, wherein the value of the switch-backthreshold is lower than that of the switch threshold. When the networkdevice 151 receives the load switch-back command, the network device 151performs the load switch-back mode for performing the normalfunctionalities of the network device 151.

Assuming the switch threshold of the first LBD 121 is 10,000 sessions.When the number of sessions in the first LBD 121 reaches 10,000, thenthe first server cluster 12 enters to the overload state and the SDNcontroller 11 executes the aforementioned process to implement thetransfer of access. The switch-back threshold is usually less than10,000 sessions, and assuming the switch-back threshold may be 8,000sessions. That is, when the number of sessions of the first servercluster 12 is 8,500 and is less than 10,000, the SDN controller 11 willnot send the load switch-back command to the network device 151 to avoidfrequent switching/switching-back. FIG. 6 is a flowchart of a method forload balancing across cluster in a SDN controller in an example of thepresent disclosure. Please refer to FIG. 6, in a more detailed example,the processes of the SDN controller 11 are as follows:

In block 601, the SDN controller 11 receives the load information whichis sent from the first server cluster 12.

In block 602, the SDN controller 11 checks the state change of the firstserver cluster in a cross-cluster table.

In block 603, the SDN controller 11 searches the cross-cluster table tofind a search target server cluster that is in an idle state which islocated in a server cluster group as the first server cluster 12 whenthe first server cluster 12 is in the overload state. At the same time,the SDN controller 11 sends a load switch command to a predeterminednetwork device which is located in a front path of the first servercluster 12, wherein the load switch command has identification of thesource server cluster and identification of a target server cluster. Theload switch command may be sent simultaneously with the searching of thecross-cluster table.

In block 604, the SDN controller 11 sends a load switch-back command tothe predetermined network device which is located in the front path ofthe first server cluster 12 when the first server cluster 12 isdetermined to be exited from the overload state, wherein the loadswitch-back command has identification of the source server cluster.

From the above description, it can be found that after the predeterminednetwork device, such as the network device 151 or the first LBD 121,transfers the new accesses of the first server cluster 12 to the targetserver cluster, the number of the sessions of the first server cluster12 will gradually decrease and approach to the switch-back thresholdbecause the established session of the first server cluster 12 isgradually aging or the users exit session. Once the switch-backthreshold is reached, the SDN controller 11 can decide that the firstserver cluster 12 exits the overloaded state, and can implement theoperations for transferring the new consecutive access back to the firstserver cluster for processing according to the corresponding step inblock 604.

Similarly, in order to maintain the consistency of the service, thosesessions which are temporarily transferred to the second server cluster13 can still be processed by the second server cluster 13. The networkdevice 151 can continue to acting as proxy for the sessions which havebeen listed in the proxy session table. Thus, it allows the packets ofthose sessions to be processed by the second server cluster 13. Inimplementation, when the network device 151 acts as proxy for theexternal host to access the second server cluster 13, the network device151 saves corresponding proxy session records in the proxy sessiontable. Accordingly, when the network device 151 receives loadswitch-back command which is sent from the SDN controller, the networkdevice 151 performs a switch-back processing mode for the first servercluster in the load switch-back command. In the switch-back processingmode, the network device performs the following operations. The networkdevice 151 searches the proxy session table based on the sessioncharacteristics of the request to query whether there is a matchedrecord when the network device 151 receives the access request of thefirst server cluster 12, if there is a matched record in the proxysession table, then the network device 151 continues to act as proxy toaccess the second server cluster 13, otherwise, the network device 151forwards the request to the first server cluster 12. After a period oftime, when each of sessions in the proxy session table is aging orexiting, the proxy session table no longer has any records. At thistime, all packets for accessing the first server cluster 12 areprocessed by the first server cluster 12.

The aforementioned descriptions illustrate the processes of loadswitching and switching-back. It is worth noting that the switching andswitching-back of the load do not occur frequently and the duration isnot too long, unless the network is not reasonable deployed by theadministrator. Therefore, processing stress of the SDN controller andthe predetermined network device 151 is also acceptable.

In the above example, the network device 151 undertakes the role of anauxiliary controller for switching/switching-back in the network. Asdescribed in the previous, other network device, such as the first LBD121, which is located in the front path can also undertake the role ofthe auxiliary controller. When the first LBD 121 is designated as thepredetermined network device, the processing of the first LBD 121 issimpler than that of the network device 151. First, the first LBD 121does not need the session list table which is sent from the SDNcontroller 11 in synchronicity because the first LBD 121 itself holdsthe session list table of the first server cluster 12. Second, the firstLBD 121 does not need to download the classification rules of the packetbecause packets which arrives the first LBD 121 are clearly to accessthe first server cluster 12. However, using of the network device 151 toprocess also has its advantages. The reason that the first servercluster entering the overload state may be the result of the first LBD121 suffered processing capacity bottlenecks. At this moment, if thetasks of the proxy access to the second server cluster 13 aretransferred to the first LBD 121, then it may increase the processingload of the first LBD 121. The processing load of the first LBD 121 isnot very light at this moment, even if the reason that the first servercluster enters the overload state is not the result of the first LBD 121suffered processing capacity bottlenecks. To add proxy access to thefirst LBD 121 may lead the first LBD 121 to encounter processingcapacity bottlenecks. In the process of implementation, theadministrator can select a reasonable predetermined network device basedon the actual situation of the network to perform the processing ofaccess transfer.

The above are only preferred examples of the present disclosure is notintended to limit the invention within the spirit and principles of thepresent disclosure, any changes made, equivalent replacement, orimprovement in the protection of the present disclosure should containwithin the scope of the disclosure.

The methods, processes and units described herein may be implemented byhardware (including hardware logic circuitry), software or firmware or acombination thereof. The term ‘processor’ is to be interpreted broadlyto include a processing unit, ASIC, logic unit, or programmable gatearray etc. The processes, methods and functional units may all beperformed by the one or more processors; reference in this disclosure orthe claims to a ‘processor’ should thus be interpreted to mean ‘one ormore processors’.

Further, the processes, methods and functional units described in thisdisclosure may be implemented in the form of a computer softwareproduct. The computer software product is stored in a storage medium andcomprises a plurality of instructions for making a processor toimplement the methods recited in the examples of the present disclosure.

The figures are only illustrations of an example, wherein the units orprocedure shown in the figures are not necessarily essential forimplementing the present disclosure. Those skilled in the art willunderstand that the units in the device in the example can be arrangedin the device in the examples as described, or can be alternativelylocated in one or more devices different from that in the examples. Theunits in the examples described can be combined into one module orfurther divided into a plurality of sub-units.

Although the flowcharts described show a specific order of execution,the order of execution may differ from that which is depicted. Forexample, the order of execution of two or more blocks may be changedrelative to the order shown. Also, two or more blocks shown insuccession may be executed concurrently or with partial concurrence. Allsuch variations are within the scope of the present disclosure.

Throughout the present disclosure, the word “comprise”, or variationssuch as “comprises” or “comprising”, will be understood to imply theinclusion of a stated element, integer or block, or group of elements,integers or blocks, but not the exclusion of any other element, integeror block, or group of elements, integers or blocks.

It will be appreciated by persons skilled in the art that numerousvariations and/or modifications may be made to the above-describedembodiments, without departing from the broad general scope of thepresent disclosure. The present embodiments are, therefore, to beconsidered in all respects as illustrative and not restrictive.

The invention claimed is:
 1. A method for transferring access acrossdusters, comprising: receiving, by a network device, a load switchcommand from a software defined network (SDN) controller, wherein theload switch command includes identification of a source server clusterand identification of a target server cluster, and wherein the sourceserver cluster and the target server cluster belong to a server clustergroup; and enable a switch processing mode for the source servercluster, comprising: receiving a packet destined to the source servercluster; determining whether the packet belongs to a session which hasalready been established for the source server cluster, and based on thedetermination that the packet belongs to a session which has alreadybeen established for the source server cluster, forwarding the packet tothe source server cluster.
 2. The method of claim 1 comprising:periodically receiving a session list of the source server cluster. 3.The method of claim 1 comprising: creating a record in a proxy sessiontable based on the external host accessing the target server cluster byproxy; receiving a load switch-back command from the SDN controller;enabling a switch-back processing mode for a first server cluster basedon an identification of the source server cluster in the load switchcommand, comprising: receiving a packet from an external host to requestaccess to the source service cluster, determining whether the packetmatches with a record in the proxy session table, and in response to thedetermination that the packet matches with a record in the proxy sessiontable, acting as proxy for the external host to access the target servercluster.
 4. The method of claim 1, further comprising: acting as a proxyfor an external host to access the target server cluster, based on thedetermination the packet does not belong to the session.
 5. Anon-transitory computer readable medium including instructions that,when executed by processing circuitry, cause a device to: receive a loadswitch command from a software defined networking (SDN) controller,wherein the load switch command includes identification of a sourceserver cluster and identification of a target server cluster, andwherein the source server cluster and the target server cluster belongto a server cluster group; enable a switch processing mode for thesource server cluster; receive a packet destined to the source servercluster; determine whether the packet corresponds to a session which hasalready been established for the source server cluster; and in responseto the determination that the packet corresponds to the session whichhas already been established for the source server cluster, forward thepacket to the source server cluster.
 6. The non-transitory computerreadable medium of claim 5, wherein the instructions further cause thedevice to: periodically receive a session list of the source servercluster from the SDN controller.
 7. The non-transitory computer readablemedium of claim 6, wherein the instructions further cause the device to:create a record in a proxy session table when the external host accessesthe target server cluster by proxy; receive a load switch-back commandfrom the SDN controller; enable a switch-back mode for a first servercluster based on the identification of the source server cluster in theload switch instruction; determine whether a packet matches with arecord in the proxy session table when the packet is received from theexternal host destined for the source server cluster in the switch-backmode; and based on the determination that the packet matches with therecord in the proxy session table, act as a proxy for the external hostto access the target server cluster.